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FOREWORD 


The  micro  implemented  loader  (MIL)  was  designed  and  implemented  as  a capa- 
bility of  an  operating  system  called  EASY  (Emulation  Aid  System)  for  the  Nano- 
data QM-1  microprogrammable  computer  at  NSWC.  The  project  was  supported  by  the 
FBM  Geoballistics  Division  and  by  the  Computer  Facilities  Division. 

This  report  was  reviewed  by  Mr.  Hermon  W.  Thombs,  Head  of  the  Programming 
Systems  Branch,  Computer  Programming  Division. 


Released  by: 

RALPH  A.  NIEMANN,  Head 
Strategic  Systems  Department 
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INTRODUCTION 


During  the  requirements  definition  phase  of  a project  for  the  development 
of  an  operating  system  called  EASY  (Emulation  Aid  System),1,2  the  need  for  an 
effective  and  efficient  program  loading  facility  was  noted.  A loader  was  re- 
quired that  supported  linking,  libraries,  overlays,  and,  if  possible,  dynamic 
allocation  and  delocation  of  code  modules.  There  was  a serious  time  and  man- 
power constraint  that  made  minimal  implementation  mandatory.  Since  this  need 
became  apparent  early  in  the  operating  system  project,  it  was  possible  to  in- 
fluence the  design  of  the  operating  system  and  the  underlying  control  structure 
of  the  machine  architecture.  The  high-level  language  SIMPL®'4  was  chosen  as 
the  language  for  implementing  system  and  user  routines.  Also,  the  implementor 
of  the  compiler  for  the  SIMPL  computer  programming  language  was  available  to 
generate  the  object  code  in  the  structure  specified. 

A search  of  the  literature  revealed  only  meager  information  on  loaders.5-® 
Very  little  information  on  the  subject  stating  useful  general  principles  with 
respect  to  microprogrammable  computer  loading  was  found. 

The  goal  of  the  design  then  became  to  develop  a loader  facility  that  was 
flexible  and  powerful  enough  to  support  the  end  use  in  an  effective  and  efficient 
manner  but  not  to  encumber  the  end  user  or  implementor  with  unneeded  complexity. 
Mr.  Charles  W.  Flink  II  and  Mr.  John  G.  Perry,  Jr.,  helped  refine  the  design 
leading  to  implementation.  The  micro  implemented  loader  (MIL)  design  was  com- 
pleted in  May  1976  and,  except  for  some  minor  enhancements,  implemented  by 
December  1976. 


FUNCTIONAL  DESCRIPTION 


OVERVIEW 

The  MIL  represents  an  advance  in  program  loading  technology  for  micropro- 
grammable computer  architectures.  The  effective  use  of  data  structures9  and 
firmware  accounts  for  the  efficiency  of  the  MIL.  Its  design  supports  all  of 
the  standard  functions  associated  with  traditional  computer  subsystems,  which 
use  complicated  linkers,  loaders,  and  library  facilities  requiring  many  thou- 
sands of  instructions  to  complete  their  tasks.  MIL  accomplishes  loading  of 
code,  linking  of  global  data,  binding  of  externals  to  entry  points,  and  code 
relocation  without  the  expected  complexity.  The  more  advanced  loader  functions 
such  as  libraries  and  bound  object  code  modules  (i.e.,  sometimes  referred  to 
as  overlays  or  segments)  are  also  supported.  These  bound  object  modules  are 
dynamically  loaded  and  freed. 
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Finally,  there  is  the  almost  unique  feature  of  delaying  binding  until 
the  actual  time  of  first  execution  of  the  instruction  that  references  the  external 
or  global  data.  The  Burroughs  Corporation  B7000/B6000  computer  user  loader 
has  this  characteristic.*0  This  feature  makes  for  a more  efficient  utilization 
of  computer  resources.  It  also  saves  on  computer  processor  utilization  and 
canputer  memory  space,  since  only  those  references  actually  used  in  the  particular 
run  need  be  resolved  and  reside  in  main  store. 

Traditionally,  loaders  with  this  type  of  capability  require  a large  amount 
of  code  to  perform  their  function.  The  MIL  system  has  no  high-level  code;  all 
of  the  coding  was  done  in  microcode.  The  operating  system  or  user  program  acti- 
vates the  loader  indirectly  by  any  instruction  whose  reference  is  unresolved  or 
explicitly  by  two  machine  instructions  (i.e.,  PSLOAD,  PSFREE) . The  entire 
loader  is  implemented  in  microcode  on  a Nanodata  QM-1  computer11'12  in  less  than 
200  words.  True  ease  of  implementation,  reliability,  and  efficient  operations 
can  be  obtained  when  system  functions  are  reduced  to  a module  of  this  size. 


RELOCATION 

One  of  the  fundamental  functions  of  any  loader  facility  is  the  handling  of 
relocation  of  machine  addresses.  A conventional  approach  by  a loader  facility 
might  require  all  machine  instruction  modules  to  generate  the  code  as  if  the 
module  was  going  to  execute  at  memory  address  zero.  The  loader  would  also  re- 
quire the  generator  of  the  machine  module  to  supply  the  relocator  with  a mapping 
of  what  instruction  addresses  would  have  to  be  changed  if  the  module  was  exe- 
cuted at  some  other  address  in  the  machine.  This  procedure  is  generally  neces- 
sary since  most  conventional  machines  require  machine  instructions  to  contain 
absolute  memory  address.  The  computer  needs  to  know  exactly  what  location  to 
reference.  In  traditional  loader  facilities  this  binding  of  instructions  to 
memory  address  occurs  at  load  time. 

However,  the  EASY  operating  system  resolves  this  problem  by  defining  in 
microcode  a machine  where  instruction  addresses  needing  relocation  are  replaced 
with  displacements  between  instruction  location  and  the  memory  word  referenced. 
In  order  for  the  firmware  to  compute  the  real  computer  memory  address  pointed 
to  by  the  machine  instructions,  the  microcode  adds  the  displacement  given  in 
the  machine  instruction  to  the  location  of  the  instructions.  This  sum  is  the 
absolute  memory  address  needed  to  be  referenced.  This  form  of  addressing  is 
sometimes  referred  to  as  relative  addressing. 

Since  all  code  generated  for  this  micro  machine  is  done  by  one  translator, 
the  computation  of  this  displacement  is  handled  transparently  to  the  end  user. 
Implementation  of  this  design  feature  eliminates  a large  part  of  the  overhead 
performed  by  the  loader. 


LINKING 

Another  fundamental  function  of  any  loader  is  the  linking  together  of 
separately  generated  load  modules.  It  is  very  useful  for  a routine  generated 
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at  one  time  to  reference  another  routine  or  data  location  generated  at  some 
other  time.  The  traditional  method  is  to  modify  the  instructions  address  of 
all  references  to  the  external  location  with  absolute  address  of  the  location 
before  execution  starts.  This  approach  requires  much  overhead  in  table  space 
and  central  processor  time  for  externals  possibly  not  used.  This  process  is 
generally  known  as  resolution  of  external  references,  binding,  or  linking. 

The  MIL  design  takes  a different  approach.  No  resolution  of  externals 
takes  place  until  the  actual  instruction  referencing  the  external  is  executed. 
The  firmware  is  aware  of  a link  list  of  entry  points  running  through  the  machine 
code  modules.  The  firmware  makes  use  of  this  data  structure  to  resolve  the  ad- 
dress dynamically.  MIL  may  load  a module  into  core  to  satisfy  the  external  re- 
quired. 


DETAILED  DESCRIPTION 


THE  OBJECT  MODULE  DATA  STRUCTURE 

A detailed  description  of  the  data  structures  of  the  object  modules  and 
their  relation  to  other  parts  of  the  system  is  presented  in  this  section.  Each 
object/load  module  can  consist  of  up  to  seven  separate  tables.  The  format  and 
relation  of  each  table  are  illustrated  in  Figure  1.  The  labeis  associated  with 
the  first  word  address  of  each  table  are  given  on  the  left  of  the  figure.  The 
tables  are 


MHDR* 

Module  Header  Table 

MID* 

Module  ID  Table 

EXTM 

External  Name  Table 

GLOBALS 

Globa Is  Table 

ENTM* 

Entry  Point  Name  Table 

TEXT 

Text  Table 

ENDM* 

End  Module  Table 

* Required  as  part  of  any  object  module 


It  should  be  noted  that,  in  this  particular  implementation,  program  space 
started  at  high  memory  addresses  and  grew  towards  low  memory  addresses.  So  the 
"top"  or  oldest  module  is  found  at  the  foot  of  the  diagram,  and  the  most  newly 
loaded  module  or  "bottom"  is  at  the  head  of  the  diagram.  Two  pointers.  Bottom 
of  Program  Space  (BPS)  and  Top  of  Program  Space  (TPS) , are  also  given  in  Fig- 
ure 1.  The  function  of  TPS  is  to  indicate  the  start  of  the  program  space,  where- 
as BPS  indicates  the  end  of  the  currently  used  memory.  As  more  space  is  needed, 
BPS  is  decremented. 

The  purpose  and  structure  (Figures  2 through  8)  of  each  table  illustrated 
in  Figure  1 are  presented  in  the  following  pages.  In  the  implementation  de- 
cribed,  the  tables  were  reconstructed  in  18-bit  QM-1  computer  words.  However, 
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MHOR 


MID 


EXTM 


GLOBALS 


ENTM 


TEXT 


ENTM 


ENDM 


BPS 

NEWER  MODULE 


LEGEND 


DATA 


CODE 


MIL  TABLE 
ENTRIES 


LOWER 

MEMORY 

ADDRESSES 

▼higher 


NOTE  STAR  (*)  SIGNIFIES  THE 
VALUE  OF  THE  CURRENT 
RELATIVE  LOCATION  IN  THIS 
MODULE  THUS  MHDR  * 

IS  A RELATIVE  POINTER 
TO  THE  BEGINNING  OF 
THE  MODULE 


OLDER  MODULE 


TPS 


Figure  1.  MIL  Load  Module  with  2 Externals  EXTl,  EXT2 
and  2 Entry  Points  ENTl , ENT2 
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the  EASY  user  is  only  aware  of  the  machine  as  a 36- bit  machine.  Transparent  to 
the  user  two  QM-1  words  were  used  to  make  a SIMPL-Q  word.  However,  18-bit 
fields  are  efficiently  implemented  in  this  application  so  most  of  the  fields 
are  half  EASY  words. 


Module  Header  Table  (MHDR) 

Purpose 

1.  To  identify  start  of  a legitimate  module 

2.  To  function  as  a dummy  external  link 

3.  To  allow  location  of  other  tables  within  the  module  to  be  defined 


777777 8 

LENGTH  OF  MODULE 

FIRST  EXT  POINTER 

0 

MID  POINTER 



LENGTH  OF  MID 

GLOBALS  POINTER 





LENGTH  OF  GLOBALS 

Figure  2.  Module  Header  Table 


Description  of  Entries 

Word  0 - All  sevens  to  flag  start  of  module 

- Used  with  word  1 to  form  a dummy  external  name 

1 - Length  of  module,  binary  number 

- A relative  pointer  to  start  of  next  higher  module 

2 - Relative  pointer  to  first  external  item  in  module  or, 

if  none,  to  ENDM  + 4 (i.e.,  the  next  MHDR) 

3 - Zero 

4 - Relative  pointer  to  module  ID  table 

5 - Length  of  module  ID  table 

6 - Relative  pointer  to  globals  table 

7 - Length  of  globals  table 
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Note 


A 


If  other  tables  are  needed  in  the  future,  a relative  pointer  should  be 
inserted  at  the  end  of  the  header  table  along  with  a word  containing  the  length 
of  the  table. 


Module  ID  Table  (MID) 

Purpose 

To  allow  human  identification  of  the  module 


MID  0 

2 

4 


Description  of  Entries 

Word  0 and  1 used  to  contain  name  of  module  as  defined  in  SIMPL-Q 

2 - Version  number  of  SIMPL-Q  compiler  being  used  to  generate 

module  (binary  number) 

3 - Relative  pointer  to  start  of  next  higher  module  in  core  (i.e., 

next  MHDR) 

4 - Julian  date  (binary  number  representing  YYDDD) 

5 - Time  of  compilation  (binary  integer  representing  HHJWSS) 


MODULE  NAME 

VERSION  H 

ENDM  + 4 — * 

JULIAN  DATE 



TIME 

Figure  3.  Module  ID  Table 


Note 

This  table  contains  human  identification  information.  For  this  table  and 
all  other  loader  tables,  names  are  1-6  characters  represented  with  6-bit  ASCII 
characters.  All  names  start  with  an  alpha  character  (01-33  octal)  and  are  left- 
justified  within  the  word  and  zero-filled.  If  the  name  is  used  for  external  or 
entry  data  (as  opposed  to  external  or  entry  PROC/FUNC) , then  the  leftmost  bit 
is  set  to  1.  This  guarantees  that  external  linkages  can  only  be  made  to  the 
correct  type  of  links. 
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External  Module  Table  (EXTM) 


Purpose 

To  allow  an  external  reference  to  be  satisfied  dynamically 


EXTM 


0 


2 


EXTERNAL  NAME 

LINK  TO  ^ EXTERNAL  ADDRESS 

NEXT  EXTERNAL  , OR  ZERO 


Figure  4.  External  Module  Table 


Description  of  Entries 

This  table  consists  of  zero  or  more  quadruples  of  words  of  the  following 
format  linked  together. 

Word  0 and  l - Name  of  external,  up  to  six  6-bit  coded  characters 

2 - Relative  pointer  to  next  external  quadruple 

3 - Initially  zero;  when  resolved,  the  relative  address 

corresponding  to  the  external  name 


Note 


All  references  to  this  external  within  a module  normally  refer  to  the  same 
quadruple. 

In  large  modules  where  a reference  to  this  table  may  be  greater  than  lOOOOg 
locations,  a second  table  for  the  same  external  name  will  be  generated.  Caution 
must  be  used  in  dynamically  redefining  such  multiple  external  tables,  since  the 
table  could  be  redefined  and  another  table  used  in  the  call  statement  executed. 

The  names  of  all  external  data  references  are  coded  so  a distinction  between 
transfer  (call)  and  a data  reference  can  be  achieved.  Data  references  have  the 
high-order  bit  of  the  first  character  set. 
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Globa Is  Table 


Purpose 

To  group  all  global  variables  together 


GLOBALS 


I ENTRY  POINT  TABLE 
IN  GLOBALS 
TABLE 


Figure  5.  Globa Is  Table  Containing  an  Entry  Point  Table 


Description: 

The  globals  table  consists  of  zero  or  more  locations  for  global  variables. 
If  it  is  an  entry  global  variable,  then  an  entry  table  (with  the  global  name 
coded  as  a data  item)  precedes  the  location  of  the  global  variable. 


Entry  Table  (BJTM) 


Purpose 

To  allow  reference  of  data  or  PROC/FUNC  from  another  module 
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Description 


An  entry  table  may  occur  in  one  of  two  places — either  in  the  globals  table 
(as  shown  in  Pigure  5)  for  a data  item  or  in  the  text  table  (EASY  code)  for 
ENTRY  PROC  or  FUNC  (Pigure  6).  In  either  case,  the  item  (code  or  data)  being 
referenced  immediately  follows  the  entry  table.  Regardless  of  the  location 
of  an  entry  point,  the  format  is: 


Word  0 


Relative  pointer  to  the  preceding  entry  point  in  the  module; 
if  none,  then  relative  pointer  to  2 words  before  module  (i.e 
EtOM  t 2 of  preceding  module) 


Relative  pointer  to  module  header  table 


Name  of  the  global  or  entry  point 


Data  names  for  globals  and  PROC/FUNC  must  follow  the  convention  discussed 
under  the  module  ID  table. 


Text  Table 


To  provide  an  area  for  executable  code 


TEXT 


POINTER  TO 
NEXT  ENTRY 


ENTRY  POINT 
TABLE  IN 
TEXT  TABLE 


ENTRY  NAME 


TEXT  FOR 
PROC  A 


Figure  7.  Text  Table  Containing  an  Entry  Point  Table 


Description 


This  area  of  the  object  module  contains  the  EASY  machine  language  code 

for  the  program.  It  also  may  contain  entry  tables  if  there  are  entry  points 
for  PROC/FUNC  in  the  module. 


End  Table  (ENDM) 


Purpose 

1.  To  identify  the  end  of  a module 

2.  To  function  as  a dumny-entry  link  into  a module 


LINK  TO  I ~ 

END  " 0 LAST  ENTRY  POINT  MHDR  - * 

IN  MODULE  i 


2 7070707070708 


Figure  8.  End  Table 


Description 
Word  0 
1 

2 & 3 


of  Entries 

- Relative  pointer  to  last  entry  point  in  the  module 

- Relative  pointer  to  MHDR 

- 707070707070  Octal.  Dumny  name  for  pseudo  entry  point  in  module 


Note 


Entry  links  point  toward  low  memory,  and  external  links  point  in  the  other 
direction.  This  choice  was  made  so  that  the  most  often  referenced  entry  points 
would  be  found  the  quickest. 


LINKING  ALGORITHM 

During  execution  when  a program  addresses  some  procedure  or  data  outside 
of  its  own  module,  a special  microaddressing  method  is  invoked.  The  machine 
instruction  referencing  the  external  does  so  indirectly  through  a two-word  ex- 
ternal table  (see  Figure  4) . The  machine  instruction  also  causes  the  special 
microaddressing  method  to  be  invoked.  This  microaddressing  method  examines 
the  external  table  address  field  for  a non-zero  value.  If  non-zero,  it  will 
use  this  value  as  the  relative  memory  address  for  the  memory  reference  or  jump 
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instruction  being  executed.  If  the  micro  instruction  finds  a zero  address 
value,  the  firmware  will  search  all  entry  point  tables  (see  Figure  6)  for  a 
name  matching  the  external  name.  On  finding  a match  it  uses  the  memory  loca- 
tion of  the  next  address  after  the  entry  point  name  for  the  external  address. 

This  address  is  made  relative  to  the  external  table  and  is  written  into  the  ex- 
ternal table  address  field  and  the  machine  instruction  proceeds. 

If  the  micro  instruction  cannot  find  an  entry  point  to  match  this  name  in 
memory  and  the  external  was  a PROC  or  FUNC  reference  (CALL) , then  the  loader 
can  search  its  directories  (libraries)  for  an  entry  point  name  matching  the  ex- 
ternal name.  If  the  external  was  a data  reference,  then  the  program  is  aborted. 
The  reasoning  is  that  the  user  should  have  data  in  memory  before  accessing  it 
(this  restriction  may  be  debatable).  Once  found,  the  loader  firmware  loads 
this  routine  into  memory,  which  writes  (i.e.,  a block  copy)  the  module  directly 
into  memory  starting  at  the  next  available  location  by  the  BPS  pointer.  BPS 
is  then  set  to  be  the  first  location  of  the  module  loaded.  Therefore,  the 
chain  of  external  tables  always  starts  at  a fixed  offset  from  the  BPS  and  ends 
at  TPS.  Likewise,  the  chain  of  entry  tables  always  starts  in  a fixed  relation 
to  the  TPS  and  ends  at  BPS.  Module  loading  in  this  manner  allows  the  modules 
to  be  linked  into  the  existing  chains  without  any  modification  (e.g.,  relocation, 
resolution) . 

If  the  loader  routine  cannot  resolve  the  external,  then  the  name  is  un- 
satisfiable  and  the  user  program  is  aborted.*  If  the  module  has  been  found 
and  loaded  into  memory,  then  the  instruction  which  referenced  the  external 
is  reexecuted.  This  time  the  micro  instruction  finds  the  entry  point  and 
normal  execution  continues. 

As  part  of  this  load  function  the  system  routine  (PSLOAD)  must  validate 
that  the  module  is  valid  and  there  is  enough  field  length  between  TPS  and  Top 
of  Working  Storage  before  loading  programs.  The  PSLOAD  function  can  be  exe- 
cuted explicitly  from  the  high-level  language  and  load  a module. 


LIBRARY  FUNCTIONS 

The  storage  of  routines  on  a file  with  a directory  is  referred  to  as  a 
library.  Loaders  traditionally  reference  a file  with  a directory  to  place  in- 
to core  frequently  accessed  routines  needed  by  other  load  modules.  SORT  and 
input/ output  (I/O)  routines  are  examples  of  routines  frequently  needed  by  other 
modules.  It  is  very  desirable  to  have  this  type  of  routine  accessible  to  other 
modules  in  a transparent  (as  possible)  method. 

MIL  supports  this  feature  by  using  the  operating  systems'  file  directory 
features.  The  names  of  the  different  files  in  a particular  file  library  are 
the  entry  point  names  of  the  modules  referenced.  Thus  the  standard  file  mech- 
anism of  the  operation  system  is  converted  into  a list  of  entry  points  and  the 


* Unless  the  user  has  previously  informed  the  operating  system  to  return 
control  with  (or  without)  an  informative  message. 


ill- 


location  of  the  modules  containing  them.  The  firmware  uses  the  file  directory 
mechanism  to  locate  the  module  and  then  issues  an  I/O  to  transfer  the  required 
module  into  memory. 

BOUND  OBJECT  CODE  MODULES 


Segment  loading  capability  can  be  accomplished  (as  explained  above)  by 
making  a call  to  an  entry  PROC/FUNC  not  residing  in  memory.  Overlay  loading  can 
be  accomplished  with  the  aid  of  a simple  copy  utility  which  forms  a single  mod- 
ule of  all  modules  common  to  one  overlay.  This  overlay  is  then  stored  in  the 
file  directory  for  MIL  with  its  primary  entry  point  as  file  name.  Any  external 
reference  to  this  entry  point  name  will  cause  the  entire  overlay  to  be  loaded. 
Execution  of  the  overlay  will  start  if  it  is  a procedure  entry  point  name. 


DYNAMIC  LOADING  AND  FREEING  OF  OBJECT  MODULES 

To  load  an  overlay,  a call  is  made  to  its  external  reference  name.  An 
entire  overlay  program  space  can  be  released  by  delinking  any  entry  point  in 
that  overlay.  Module  delinking  (freeing  program  space)  is  accomplished  by 
the  high-level  statement  PSFREE  that  translates  into  a micro  instruction.  The 
operand  for  this  instruction  is  the  address  of  any  entry  point  in  the  module 
that  is  to  be  deallocated. 

All  modules  with  lower  addresses  than  this  module  will  also  be  deallocated 
at  the  same  time.  The  micro  algorithm  uses  the  pointer  which  links  to  the 
beginning  of  a module  to  find  the  length  of  the  module  and  therefore  its  last 
word  address.  Once  this  address  is  known,  the  algorthim  then  checks  the  stack 
used  by  SIMPL-Q.  This  is  to  insure  that  deallocation  of  the  module (s)  will 
not  leave  an  activated  stack  entry  for  a module  but  no  module  to  return  control 
to.  When  this  ch«ck  is  satisfied,  pointers  are  adjusted  for  freeing  of  object 
modules.  This  is  accomplished  by  setting  the  BPS  to  the  location  before  the 
module  being  delinked.  Also,  the  external  address  fields  of  the  remaining 
external  tables  that  reference  the  module  just  delinked  are  zeroed.  This  is 
performed  by  checking  the  addresses  in  the  external  chain  against  the  new  BPS. 

If  the  address  is  less  than  the  current  BPS,  then  the  address  is  set  to  zero. 

If  the  PSFREE  request  cannot  be  accomplished  because  of  active  modules  with 
lower  address  than  the  current  module  requesting  being  freed,  then  the  request 
is  modified  to  deallocate  as  much  of  the  program  space  as  possible  or  the  re- 
quest becomes  a no  operation  (NOOP) . 


The  functions  performed  by  the  micro  implemented  loader  allow  for  a wide 


range  of  capabilities  without  undue  complexity.  The  design  relies  on  a micropro- 
i granmable  processor's  ability  to  redefine  the  machine's  apparent  architecture 

and  data  structures  to  develop  a relatively  small  comprehensible  approach.  The 
implementation  has  shown  that  this  approach  is  easily  produced,  efficient,  and 
adequate  for  the  needs  of  the  users. 
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